REMARKS 



1 . Summary of the Office Action 

In the non-final Office Action mailed April 27, 2011, the Examiner rejected claims 
66-75 under 35 U.S.C. § 1 12, ^ 2 as allegedly being indefinite. The Examiner rejected 
claims 1-3, 5, 7-9, 14, 15, 17-19, 21, 22, 24-26, 29, 33, 35-38, 66-71, and 76-81 under 
35 U.S.C. § 103(a) as allegedly being unpatentable over U.S. Patent App. Pub. No. 
2003/0154243 ("Crockett") and in further view of U.S. Patent App. Pub. No. 
2003/0216140 ("Chambert"). 

The Examiner rejected claims 4, 6, 10, and 23 under 35 U.S.C. § 103(a) as 
allegedly being unpatentable over Crockett in view of Chambert and in further view of 
U.S. Patent App. Pub. No. 2002/0165969 ("Gallant"). 

The Examiner rejected claims 11-13, 16, 20, 27, 28, 39-42, 72-75, and 82-85 
under 35 U.S.C. § 103(a) as allegedly being unpatentable over Crockett in view of 
Chambert and in further view of U.S. Patent No. 7,170,863 ("Denman"). 



2. Response to Interview Held June 14, 2011 

On June 14, 2011, Tom Loos for the Applicant interviewed the Examiner via 

telephone. Prior to the interview, Applicant provided the Examiner with the proposed 

amendments to claim 1 : 

1 . (Currently Amended) A system, comprising: 

a first session initiation protocol (SIP) proxy, configured to: 

support routing of communications for a first plurality of clients in a first 
region, wherein the communications comprise push-to-talk communications, and 
to store a value of a local domain for the first region; 

wh e r ei n a f i rst c lie nt of th e f i rst p l ura li ty of c lie nts i s conf i gur e d to r e g i st e r w i th a 
th e s e cond S I P proxy and opt i ona ll y w i th th e first S I P proxy; 

client of the first plurality of clients is registered with the first SIP proxy, wherein the first 
client is configured to optionally register with the first SIP proxy , and wherein the first 
client is associated with a predetermined home domain; [[,]] and[[,]] 

in response to determining that the first client is registered with the first SIP proxy: 
determine whether or not a push - to - ta l k commun i cat i on or i g i nat e d by the 

f i rst c lie nt home domain is the local domain for [[to]] the first region; bas e d at le ast 

i n part on th e stor e d va l u e of th e l ocal doma i n, 
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set up a push-to-talk communication in the first region responsive to 
determining that the push to ta l k commun i cat i on home domain is the local 
domain; [[,11 and 

set up the push-to-talk communication in [[the]] a second region 
responsive to determining that the push - to - ta l k commun i cat i on home domain is 
not the local domain . 

Regarding the § 112 rejections, Applicant argued that at least paragraphs 0019- 
0021, 0026, 0028-0032, 0038-0040, and 0043-0050 of the Specification supported 
claims 66-75. The Examiner was not persuaded by Applicant's argument and provided 
some helpful suggestions. Applicant agreed to take the Examiner's suggestions into 
account. 

Regarding the § 103 rejections, Applicant argued that the cited art did not 
disclose or suggest the features of "the first client is associated with a predetermined 
home domain" and "in response to determining that the first client is registered with the 
first SIP proxy: determine whether or not the home domain is the local domain for the 
first region; set up a push-to-talk communication in the first region responsive to 
determining that the home domain is the local domain; and set up the push-to-talk 
communication in a second region responsive to determining that the home domain is 
not the local domain" as recited in the proposed amended claim 1. The Examiner 
agreed with Applicant's argument. 

No other art, claims, or pertinent issues were discussed. 

Applicant thanks the Examiner for sharing his time and expertise during the 
interview. 



3. Status of the Claims 

Previously, claims 30-32, 34, and 50-65 were cancelled and claims 43-49 were 
withdrawn. In this response, claims 1 , 29, 66, and 76 have been amended as discussed 
herein. Also, claims 3, 5, 10, 16, and 38, have been amended to clarify and/or align 
their language with their respective independent claims. Support for these amendments 
can be found generally throughout the application, and specifically in at least fflj 0050, 
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0054-0056 and 0068-0070. Now pending are claims 1-29, 33, 35-49, and 66-85, among 
which only claims 1, 29, 43, 66, and 76 are independent claims. 

The amendments to the claims are generally supported by the specification as 
filed, are made without prejudice or disclaimer, and solely made for the purposes of 
expediting prosecution. Applicant expressly reserves the right to pursue the subject 
matter of any previous claims in a continuation application. 

4. Response to the Rejections of Claims 66-75 under 35 U.S.C. § 1 12, U 2 

The Examiner rejected claims 66-75 under 35 U.S.C. § 112, If 2 as being 
indefinite. More specifically, the Examiner asserted that for "claim 66, apparatus claims 
'means for determining', "means for receiving', 'means for storing', 'means for 
determining', 'means for determining', 'means for determining' are means plus function 
limitation[s] that invok[e] 35 U.S.C. 112, sixth paragraph. However, the written 
description fails to clearly like or associate the disclosed structure, material, or acts to 
the claimed function such that one of ordinary skill in the art would recognize what 
structure, material or acts performed the claimed function." Office Action, p. 3 

Applicant respectfully disagrees. Rather, the specification teaches that a system 
that comprises one or more SIP proxies, each SIP proxy comprising a SIP proxy engine 
and a push-to-talk server interface, can be utilized to provide the various means recited 
in claim 66 as quoted below. 

The specification atfflj 0020-21 teaches in part (with emphasis added): 

[A]n illustrative system 10 comprises one or more SIP proxies 11. ... 
In a preferred embodiment at least one of these SIP proxies 11 is 
operably coupled to at least one memory 12. This memory 12 can 
comprise a standalone platform (as suggested by the illustration) or can 
comprise a partially or wholly integrated element of one or more of the SIP 
proxies 1 1 themselves. Those skilled in the art will also appreciate that 
such memory can comprise a local resource or can be remotely located 
with respect to the SIP proxies 11. Such memory 12 can serve a variety of 
useful purposes. For example, such memory 12 can serve to store user 
identifier information to thereby facilitate the actions described herein. 



McDonnell Boehnen Hulbert & Berghoff LLP MBHB Case No.: 08-968 

300 South Wacker Drive ' D Application Serial No.: 1 0/840,083 

CHICAGO, ILLINOIS 60606 FILING DATE: MAY 6, 2004 
TELEPHONE (312) 913-0001 



The specification at fflj 0026 teaches a "SIP proxy", "SIP proxy engine" with a 



"first mode of operation" and "push-to-talk server interface" as follows: (with emphasis 
added): 

[A] SIP proxy 11 comprises an SIP proxy engine and a push-to-talk 
server interface to facilitate operable coupling of the SIP proxy engine to 
an optional push-to-talk server 13. Pursuant to a preferred embodiment, 
the SIP proxy engine has at least a first mode of operation wherein 
the SIP proxy engine will facilitate a push-to-talk communication for a 
push-to-talk client that communicates an SIP message to the SIP 
proxy containing either of at least two different client identifiers as 
are available to that push-to-talk client. 

Specification, If 0026. 

The specification details the "first mode of operation" as follows: 

As another example, this first mode of operation can also comprise 
facilitation of authentication and/or registration of the push-to-talk 
client. For example, the SIP proxy can serve, if desired, as a registrar 
for mobile clients. When providing such authentication/registration 
services, a preferred approach comprises supporting a given client with 
such services regardless of whether that client presents either of at least 
two different available-to-the-client client uniform resource identifiers to 
accord with the teachings set forth above. 

As yet another example, this mode of operation can also optionally 
accommodate the making of routing decisions of SIP messages as 
are sourced by or directed to the push-to-talk client with respect to 
other portions of the system (or elements external to the system). 
Such routing decisions can be facilitated through use, for example, of 
a directory server and can be employed, if desired, to effect routing 
decisions for all SIP messages as are provided thereto. 

Yet another option is to permit the SIP proxy engine, via this first mode 
of operation, to facilitate supporting distribution of presence 
information regarding the push-to-talk client. When the SIP proxy 
supports presence service(s), such service can be provided for one or 
more of the push-to-talk clients as are located within a given region as 
corresponds to a service area for the SIP proxy. Such service can be 
facilitated in various ways including, but not limited to, by the use of 
SIP/SIMPLE messages. 

Such options can be supported given a wide variety of architectural 
conditions but may be particularly useful to employ when the relevant SIP 
proxy comprises a first hop SIP proxy with respect to the push-to-talk client 
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(that is, when there are no other SIP proxies physically or logically 
interposed between the relevant SIP proxy and the push-to-talk client). 
Aside from such elements and/or functionality as is set forth above, 
SIP proxies are well understood in the art. Therefore, additional 
embellishment and details regarding such SIP proxies are not 
provided here for the sake of brevity and the preservation of relevant 
focus except where particularly relevant to the following discussion. 

Specification, fflj0028-0030 (emphasis added). 

The specification additionally describes that 

[s]uch a system 10 serves to facilitate the communication needs of a 
plurality of clients 14 for a given region. Pursuant to these illustrative 
embodiments, at least some of these clients 14 each have a plurality of 
differing user identifiers where at least two of the plurality of differing user 
identifiers each corresponds to a same first communication service (such 
as, for example, a push-to-talk communication service) (or, in addition or in 
the alternative, some of the clients may use only a single user identifier but 
different clients within the system may use user identifiers having differing 
forms from one another — for ease of description, however, only the multi- 
identifier style of client will be referred to below in these illustrative 
descriptions). There is no particular upper limit to the number of differing 
user identifiers that can be so supported. In a preferred embodiment, at 
least one of the user identifiers comprises an identifier having a standard 
SIP uniform resource identifier format while another of the plurality of 
differing user identifiers comprises an identifier having a standard 
telecommunications uniform resource identifier format. 

As noted above, as an optional embodiment, the system 10 can 
further comprise a push-to-talk server 13 (to thereby effect support 
for push-to-talk communications services for the plurality of clients 
14). When so provided, the at least one (and preferably all when 
multiple SIP proxies are provided) of the SIP proxies 11 operably 
couples to the push-to-talk server 13 to facilitate the provision of 
such services. The push-to-talk server 13 can be comprised in accord 
with present or hereafter-developed practice. In a typical embodiment the 
push-to-talk server 13 can communicate with signaling elements using SIP 
or SIP/SIMPLE and with media components (via, for example, bearer 
paths) using RTP in accord with present well-understood practice. 

Specification, fflj0031-0032 (emphasis added). 

Applicant further requests the Examiner review and consider fflj 0038-0040 

discussing Figure 5 and 0043-0050 discussing Figure 8. 
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Applicant also notes that the specification indicates that "common but well- 
understood elements that are useful or necessary in a commercially feasible 
embodiment are often not depicted in order to facilitate a less obstructed view of these 
various embodiments of the present invention. It will also be understood that the terms 
and expressions used herein have the ordinary meaning as is usually accorded to such 
terms and expressions by those skilled in the corresponding respective areas of inquiry 
and study except where other specific meanings have otherwise been set forth herein." 
Specification, lf0019. 

Applicant believes that at least the above-quoted and cited passages of the 
specification support claim 66, teaching a system that comprises one or more SIP 
proxies, each SIP proxy comprising a SIP proxy engine and a push-to-talk server 
interface that can be utilized to provide the various means recited in claim 66. 

For at least these reasons, Applicant therefore respectfully requests the Examiner 
to reconsider and withdraw the rejections of claim 66 under 35 U.S.C. § 112, 2. And, 
for the reasons provided above for claim 66, Applicant respectfully requests the 
Examiner to reconsider and withdraw the rejections of claim 67-75 under 35 U.S.C. § 
112,H2. 

5. Response to the Rejections under 35 U.S.C. § 103 

As mentioned above, independent claims 1, 29, 66, and 76 stand rejected under 

35 U.S.C. § 103(a) over Crockett in further view of Chambert. Applicant submits that 

Crockett and Chambert, alone or in combination, do not support the rejections of claims 

1, 29, 66, and 76 for at least the reasons presented below. Further, the Examiner did 

not establish a prima facie case of obviousness of claims 1, 29, 66, and 76 under 

M.P.E.P. § 2142 (requiring an Examiner to clearly articulate reasoning with rational 

underpinning to support the conclusion of obviousness). 

a. Crockett and Chambert, alone or in combination, do not disclose or 
suggest all of the functionality recited in claim 1. Further, the Examiner has not 
made a prima facie case of obviousness for claim 1 under M.P.E.P. § 2142. 

Amended claim 1 recites, in part, use of "a first client" of a "first plurality of clients 

in a first region," and a "first SIP proxy", where the "first client .... is configured to 
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optionally register with the first SIP proxy, and wherein the first client is associated with a 
predetermined home domain," where "the first SIP proxy" is configured to "determine 
whether [the] first client ... is registered with the first SIP proxy ... [and] in response to 
determining that the first client is registered with the first SIP proxy: determine whether 
or not the home domain is the local domain, set up a push-to-talk communication in the 
first region responsive to determining the home domain is the local domain, and set up 
the push-to-talk communication in a second region responsive to determining that the 
home domain is not the local domain." 

Applicant submits that the cited art not disclose or suggest at least this quoted 
functionality as recited in amended claim 1, and therefore does not support a rejection of 
claim 1 under 35 U.S.C. § 103. 

i. Discussion of Crockett 

Crockett does not disclose or suggest at least "a first session initiation protocol 
(SIP) proxy configured to.... store a value of a local domain for the first region... 
determine whether or the first-client domain is the local domain for the first region; set up 
a push-to-talk communication in the first region responsive to determining that the first- 
client domain is the local domain; and set up the push-to-talk communication in a 
second region responsive to determining that the first-client domain is not the local 
domain" where "the first client is associated with a first-client domain" as recited in 
amended claim 1 . 

In an attempt to support the rejection of the above-quoted functionality of claim 1 , 
the Examiner stated that "Crockett: [0104]-[0105] for determining if call is intra-regional 
based on location information; [0096] provides location may be the IP address... 
Crockett: [01 06]-[01 1 1 ] for intra-regional call setup when originator and targets are in 
same region... Crockett: [0122] provides setting up the call in remote region when call is 
not local" Office Action, page 6. 

Crockett states that "[i]n a wireless communication system, e.g., CDMA system, 
registration is the process by which a mobile station makes its location known to the 
wireless system infrastructure." Crockett, If 0095. Crockett further states that "[i]n one 
embodiment, the user location information is the IP address of the client, regardless of 
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whether the client is connected via wireless or wireline services." Crockett, If 0096. 



Then, "[a]fter registration is complete, the user may make or receive calls." Crockett, ^ 
0103. 

Crockett describes use of a "regional dispatcher" that "may be the initial point of 
contact for the call setup requests and alert requests." Crockett, ^ 0058. 
In particular, Crockett mentions that 

After the regional dispatcher has determined whether the call is intra- 
regional or inter-regional, it may start the process of determining which 
media control unit (MCU) may host the call. For intra-regional calls, the 
regional dispatcher may assign the call to an MCU located in the 
same region as the regional dispatcher, if there are MCU resources 
available in that region. The resulting call using this type of call setup 
is referred to as a "locally-hosted" call, or local call. For inter-regional 
calls, the regional dispatcher may have a choice to assign the call to an 
MCU within the same region or in a remote or foreign region. The regional 
dispatcher may make this decision based on the users' location 
information to find the optimal path of travel for the IP packets 
containing media and signaling. If a majority of the users are located 
in a particular region, the call may be assigned to that region. If the 
users are evenly dispersed across regions, the call may be assigned 
to one of the regions containing the target users. If the inter-regional 
call is assigned to an MCU in different region then the region in which the 
regional dispatcher resides, the call is referred to as a "remotely-hosted" or 
remote call. The regional dispatcher may have knowledge of the network 
topology and/or connectivity between the MCUs and the PDSNs they are 
serving and may use this knowledge to make a better decision on the 
assignment of calls. 

Crockett, U 01 05 (emphasis added). See also Crockett, fflf 01 1 1 , 01 22 

While Crockett does mention the concept of a "locally-hosted" call, the decision 

on call assignment is based on where "a majority of the users are located" or "[i]f the 

users are evenly dispersed across regions, the call may be assigned to one of the 

regions containing the target users." Crockett, If 0105 (emphasis added). That is, 

Crockett discloses assigning the call to where the majority of users are, regardless of 

whether the call is locally-assigned or remotely-hosted. 

Claim 1 recites, in part, "determining] whether or not the home domain is the 

local domain for the first region." As quoted above, Crockett does not disclose or 

suggest this feature of claim 1. Additionally, Crockett does not disclose or suggest 
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"set[ting] up a push-to-talk communication in the first region responsive to determining 



that the home domain is the local domain" or "set[ting] up a push-to-talk communication 
in a second region responsive to determining that the home domain is not the local 
domain" as also recited in claim 1 . 

Rather, as quoted above, Crockett discloses that "[i[f a majority of the users are 
located in a particular region, the call may be assigned to that region." Crockett, If 0105. 
For at least these reasons, Crockett does not disclose or suggest all of the features of 
amended claim 1. 

ii. Discussion of Chamber! 

Chambert does not cure the above-mentioned deficiencies in Crockett. 

Chambert describes a "universal identification system for uniquely identifying cells 
and location areas, or more generally, access points, within wireless access networks." 
Chambert, U 0009. 

Chambert states that 

[t]he DNS name 215a of the current location area within which the mobile 
terminal 230 is located is stored in a subscriber record 250 within a 
subscriber register 240 (e.g., a Home Location Register or a distributed 
subscriber register), along with other subscriber data 255 associated with 
the mobile terminal 230. For call routing purposes, the subscriber register 
240 can access the DNS server 220, via an IP network 160c , to convert 
the stored DNS name 215 a to an IP address 225 (shown in FIG. 3) for the 
location area 200. 

A sample location update procedure is described in FIG. 6. Each base 
station maintains the DNS name of the location area associated with each 
cell that the base station serves. Each cell broadcasts the DNS name of 
the location area containing the cell on the overhead channel. For 
example, the DNS name for a location area can have a form similar to the 
following: loc-1015-stockholm.telia.se. 

Upon receipt of the location area DNS name (step 600), a mobile 
terminal compares the received DNS name to a stored DNS name of 
the location area that the mobile terminal previously registered with 
(step 610). If the received DNS name matches the stored DNS name 
(step 620), the mobile terminal has not roamed into a new location 
area, and no location update needs to be performed (step 630). 
However, if the received DNS name does not match the stored DNS 
name (step 620), the mobile terminal must register with the new 
location area by sending a location update message via the base station 
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to the subscriber register with the new location area DNS name (step 640). 
For example, to register with location area "loc- 
1015.stockholm.telia.se", the mobile terminal can send a location 
update message including the DNS name "loc- 
1015.stockholm.telia.se". 

As a result, a reference to the "loc-1015.stockholm.telia.se" is stored 
within the subscriber register. Thereafter, as shown in FIG. 7, when 
the subscriber register receives a request for routing information for 
the mobile terminal (e.g., there is an incoming call to the mobile 
terminal) (step 700), the subscriber register queries the DNS server 
for the IP address associated with the stored location area DNS name 
(step 710). The subscriber register passes this IP address back to the 
requesting entity (step 720), so that the incoming call can be properly 
routed towards the mobile terminal. 

Chambert, 0035-0038 (emphasis added). A copy of Figure 7, mentioned above, is 

provided for the Examiner's convenience: 



Subscriber Register Receive Request for 
Routing Information 

Subscriber Register Query DNS Server to 
Convert DNS name to IP Address 



IP Address Sent to requesting node as 
routing information 



FIG. 7 



The Examiner cited the above passage and Figure of Chambert, asserting that 
"Chambert... teaches determining whether a communication is local based on a stored 
value of a local domain (Chambert: Figure 7, all steps; [0035]-[0038] provides for 
retrieving routing information and IP based on FQDN of the domain.)" Office Action, 
page 6. 
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Applicant respectfully disagrees with the Examiner's interpretation of Chambert. 
In one aspect, Chambert discloses "comparing] the received DNS name [from a base 
station] to a stored DNS name of the location area that the mobile terminal previously 
registered with (step 610). If the received DNS name matches the stored DNS name 
(step 620), the mobile terminal has not roamed into a new location area, and no location 
update needs to be performed (step 630). However, if the received DNS name does not 
match the stored DNS name (step 620), the mobile terminal must register with the new 
location area." Chambert, U 0037. 

That is, Chambert discloses comparing a "stored DNS name of the location area 
that the mobile terminal previously registered with" and a "received DNS name [from a 
base station]" to determine if registration is required. See id. However, this is not the 
same as "determining] whether or not the home domain [of the first client] is the local 
domain for [[to]] the first region" - rather, Chambert discloses comparing a previously- 
registered stored DNS name with a received DNS name. 

Further, Chambert discloses this comparison in the context of determining 
whether or not registration is required by the mobile terminal. See id. This is not the 
same as "set[ting] up a push-to-talk communication in the first region responsive to 
determining the home domain is the local domain, and set[ting] up the push-to-talk 
communication in a second region responsive to determining that the home domain is 
not the local domain" as also recited by amended claim 1 . 

In another aspect, Chamber discloses that "when the subscriber register receives 
a request for routing information for the mobile terminal (e.g., there is an incoming call to 
the mobile terminal) (step 700), the subscriber register queries the DNS server for the IP 
address associated with the stored location area DNS name (step 710). The subscriber 
register passes this IP address back to the requesting entity (step 720)..." Chambert, ^ 
0038 and Figure 7. 

Chambert provides this example: "to register with location area "loc- 
1015.stockholm.telia.se", the mobile terminal can send a location update message 
including the DNS name "loc-1015.stockholm.telia.se." As a result, a reference to the 
"loc-1015.stockholm.telia.se" is stored within the subscriber register." Chambert, ^ 
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0037-0038. That is, Chambert discloses storing the registered (e.g. , local) domain in the 
subscriber register. 

However, Chambert is silent regarding use of a "predetermined home domain" as 
recited in claim 1. As such, Chambert does not disclose or suggest "determinpng] 
whether or not the home domain is the local domain for the first region" as recited in 
amended claim 1. Additionally, Chambert does not disclose or suggest "set[ting] up a 
push-to-talk communication in the first region responsive to determining that the home 
domain is the local domain" or "set[ting] up a push-to-talk communication in a second 
region responsive to determining that the home domain is not the local domain" as also 
recited in claim 1. For at least these reasons, Applicant submits that Chambert does 
not cure the deficiencies of Crockett. 

Thus, Crockett and Chambert, alone or in combination, do not disclose or suggest 
all of the functionality recited in claim 1 . Applicant further submits that the Examiner did 
not establish a prima facie case of obviousness of claim 1 under M.P.E.P. § 2142. Thus, 
Applicant submits that the cited art does not support rejection of independent claim 1 
under 35 U.S.C. § 103. 

b. For at least the reasons presented for claim 1, the cited art does not 
support the rejections of independent claims 29, 66, and 76 under 35 U.S.C. § 103. 
Further, the Examiner has not made a prima facie case of obviousness for claims 
29, 66, and 76 under M.P.E.P. § 2142. 

Independent claims 29, 66, and 76 stand rejected under 35 U.S.C. § 103 over 
Crockett and Chambert. As amended, claims 29, 66, and 76 recite similar functionality 
to that discussed above for independent claim 1 . Thus, for at least the reasons set forth 
for claim 1, Applicant submits that the proposed Crockett/Chambert combination does 
not support rejection of independent claims 29, 66, and 76 under 35 U.S.C. § 103. 
Applicant further submits that the Examiner did not establish a prima facie case of 
obviousness of claims 1 , 29, 66 and 76 under M.P.E.P. § 2142. 

For at least these reasons, Applicant respectfully requests the Examiner 
reconsider and withdraw the rejections of claims 1, 29, 66, and 76 under 35 U.S.C. § 
103. 
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c. Applicant respectfully requests the Examiner withdraw the rejections 
of the dependent claims as well, for at least the reasons provided above. 

Further, Applicant submits that the revisions and comments directed above to 
independent claims 1 , 29, 66, and 76 apply equally to dependent claims 2-28, 33, 35-42, 
67-75, and 77-85, each of which depend directly or indirectly from claims 1, 29, 66, and 
76. On at least this basis, the Applicant requests reconsideration and withdrawal of the 
rejections of dependent claims 2-28, 33, 35-42, 67-75, and 77-85. Some of these 
dependent claims stand rejected under § 103 in view of certain other references. 
However, the Applicant submits that these other references do not cure the deficiencies 
of the proposed Tsirtsis/Denman/Crockett combination. 

Further, Applicant submits that the Examiner did not establish a prima facie case 
of obviousness of claims 2-28, 33, 35-42, 67-75, and 77-85 under M.P.E.P. § 2142. 

Therefore, Applicant respectfully requests the Examiner reconsider and withdraw 
the rejections of claims 2-28, 33, 35-42, 67-75, and 77-85 under 35 U.S.C. § 103. 

5. Conclusion 

In view of the foregoing, Applicant submits that all stated rejections have been 
addressed, and thus Applicant respectfully requests reconsideration and withdrawal of 
these rejections. The Examiner is invited to call the undersigned attorney at 312-913- 
3338 to expedite prosecution of this application. 

Respectfully submitted, 

McDonnell Boehnen 
Hulbert & Berghoff LLP 

Date: July 12, 2011 By: /Thomas J. Loos/ 

Thomas J. Loos 
Reg. No. 60,161 
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